Linear: RED-738

The e2e - checkly - windows job declares a 4-way shard matrix (1/4…4/4), but all four shards ran the entire 27-file e2e suite — the matrix bought nothing.

Root cause

Not the compound test:e2e script, which is what the symptom suggests. Args appended to A && B land at the end of B, and B is the vitest invocation, so they reach vitest fine.

The sole cause is the literal --. pnpm forwards it verbatim into the script (npm strips it), where vitest's parser collects everything after it into an argument list it never reads — so --shard is silently discarded rather than reinterpreted. That is exactly why the broken form ran green and complete instead of failing.

Verified on pnpm 10.34.1, the version CI uses:

pnpm does not intercept flags after the script name — even --reporter, which pnpm itself defines — so no separator is needed.

Also ruled out: passing the shard through an env var read by the e2e vitest config. Vitest's --shard is CLI-only and has no config-file equivalent.

Verification

A green run proves nothing here — the broken form passed too, running the full suite four times over. Two checks were done locally:

1. pnpm now echoes pnpm pack && cross-env NODE_CONFIG_DIR=./e2e/config vitest --run -c ./vitest.config.e2e.mts --shard=1/4, with no -- before the flag.
2. vitest list per shard yields a true partition — 27 unique files, no overlap, no omission:

To confirm on this PR: the four e2e - checkly - windows (n/4) logs should report file counts smaller than 27 summing to 27 (7/7/7/6). Shards 1–3 all reporting 7 is expected and correct — the discriminator is 7+7+7+6=27 against the broken 27+27+27+27=108.

What this does and does not buy

The ticket originally claimed ~4x on both time and load. More precisely:

• Total API volume against the shared test account drops ~4x (108 file-runs → 27), shortening the window it spends under load.
• Peak concurrent requests are unchanged. The e2e vitest config sets no fileParallelism/maxWorkers, so ~4 files already run at once per job: peak is ~4 shards × ~4 forks either way. If the intermittent HTTP 500s from the test-session endpoint persist, that is not evidence this flag failed to land.
• The real hot-spot win: all four shards previously ran deploy.spec.ts concurrently, each doing an account-wide cleanupProjects() sweep. Now only one does — 5 concurrent copies (4 Windows + Ubuntu) down to 2.
• Wall-clock is bounded by the heaviest shard, not total/4. deploy.spec.ts sets the floor, and globalSetup doesn't shard: every shard still pays pnpm pack plus three template installs regardless of how few files it runs.

Risk

This is the first time the suite has actually been split, so latent cross-file coupling surfaces here for the first time.

No ordering coupling exists: every mutating spec is self-isolating via uuidv4()/nanoid() IDs, and vitest already runs files in parallel forks with no ordering guarantee. But checks-list.spec.ts, checks-get.spec.ts and checks-stats.spec.ts assert on account-wide check counts and now run in shards without deploy.spec.ts populating the account. Failures isolated to those three specs indicate that assumption, not the flag. Rollback is a one-character revert.

Other changes

None — single-file change.